Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option for creating code-signing certificates. #90

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

aebruno
Copy link

@aebruno aebruno commented Nov 19, 2019

This commit adds support for signing certificates with the codeSigning extended key usage extension. Tried to make this as non-invasive as possible by adding a new function to create host certificates api with an optional array of []x509.ExtKeyUsage. This should allow adding support for other extended key usages in the future. For now, just added a simple boolean flag to the sign command with turns this on.

This commit adds support for signing certificates with the codeSigning
extended key usage extension. Tried to make this as non-invasive as
possible by adding a new function to create host certificates api with
an optional array of []x509.ExtKeyUsage. This should allow adding
support for other extended key usages in the future. For now, just added
a simple boolean flag to the sign command with turns this on.
@CLAassistant
Copy link

CLAassistant commented Nov 19, 2019

CLA assistant check
All committers have signed the CLA.

@mcpherrinm
Copy link
Contributor

What uses this? Is this like, windows kernel driver codesigning? Are there other uses?

Do codesigning certificates need the other options? Like, do you ever want to set --domains and ---ip addresses for codesigning?

@JalonSolov
Copy link

Code signing certificates are use to sign Windows drivers, executables, dlls, .cab (archive) files, PowerShell scripts, etc., etc. Also used to sign Java jars, wars, ears, ... you can even sign XML files and other things.

https://en.wikipedia.org/wiki/Code_signing

@aebruno
Copy link
Author

aebruno commented Mar 13, 2020

@mcpherrinm Apologies for the late reply. I realize this is probably an uncommon use case and may fall outside the scope of certstrap. If so, completely understand not wanting to support this and feel free to close the PR.

What uses this? Is this like, windows kernel driver codesigning? Are there other uses?

For some more background on our specific use case, we're currently using a code-signing certificate to sign binary kernel/initrd images for use with iPXE. We wanted an easy tool to manage certificates and found certstrap to be a perfect fit. For more details on how we use certstrap see here.

Do codesigning certificates need the other options? Like, do you ever want to set --domains and ---ip addresses for codesigning?

I believe what makes a code-signing certificate is just adding the codeSigning extended key usage extension. So could possibly have any options that a normal certificate could have?

@mcpherrinm
Copy link
Contributor

One of the design goals here is to make it hard to misuse certstrap, by only providing common options. While it would be possible to have an IP SAN with codesigning EKU set, is that something that would be done in practice?

I would like to avoid supporting theoretical use-cases so we can focus on proving a sensible set of features, and figure out how to support them.

There's another PR open for supporting setting arbitrary EKUs by name or OID, would that suffice for your use-case?

@aebruno
Copy link
Author

aebruno commented Apr 8, 2020

There's another PR open for supporting setting arbitrary EKUs by name or OID, would that suffice for your use-case?

Yes, supporting setting EKUs should be sufficient and likely much more generic (assuming you're referring to #57).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants